There is a need for technological platforms more flexible and easy to develop, with the ability to support migrations from physical environments to virtual ones, and the purpose to deploy models for service functions not tightly coupled to network topology and physical resources. This way it would be possible to do away with the static nature of the current deployment models that limit the introduction of new or modify existing services and/or service functions.
To address the above issues, one possible network architecture mechanism that facilitates the definition and instantiation of an ordered set of service functions and subsequent steering of traffic through them is the Service Function Chaining (SFC) architecture [1]. Other possibilities include stitching as used in state of the art cloud platforms [2].
The SFC architecture is established on topological independence from the underlying forwarding topology. In this, as may be seen on FIG. 1, data packets are classified on the ingress node for handling by the required set of Service Functions (SFs) and are then forwarded through that ordered set of functions for processing by each function in turn. As a result of this processing the packets are perhaps reclassified.
The SFC architecture includes Service Function Forwarders (SFF), as may be seen on FIG. 2, responsible for forwarding data packets received from the network to one or more SFs associated with a given SFF. Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network.
The implied order may not be a linear progression as the architecture allows for SFCs to copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions are applied.
The delivery of end-to-end services often requires various SFs including traditional network SFs (for example, firewalls and server load balancers, among others), as well as application-specific features such as HTTP header manipulation. SFs may be delivered within the context of an isolated user (e.g., a tenant) or shared amongst many users or user groups.
Current deployment models for SFs are often tightly coupled to network topology and physical resources, thus resulting in relatively rigid and static deployments. The static nature of such deployments greatly reduces and, in many cases, limits the ability of an operator to introduce new or modify existing services and/or SFs. Furthermore there is a cascading effect: changing one or more elements of a SF chain often affects other elements in the chain and/or the network elements used to construct the chain.
This issue is particularly acute in elastic service environments that require relatively rapid creation, destruction, or movement of physical or virtual SFs or network elements. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic and very granular service delivery, post facto modification, and the movement of SFs and application workloads in the existing network. The service insertion model must also retain the network and service policies and the ability to easily bind service policy to granular information such as per-subscriber state.
Non-SFC network service deployments are often coupled to network topology, whether it be physical, virtualized, or a hybrid of the two. Such dependency imposes constraints on service delivery and limits scale, capacity, and redundancy across network resources, but on the other hand allows networks operators and service users to verify the effective application of the required services to packet flows by verifying the topology.
As more service functions are required—often with strict ordering—topology changes are needed in “front” and “behind” each SF, resulting in complex network changes and device configuration. In such topologies, all traffic, whether a SF needs to be applied or not, often passes through the same strict order. But, again, this provides a strict assurance of function application.
The dynamic nature of the SFC architecture, decoupling service from topology dependencies, supports a much flexible and scalable configuration of how services are applied to packet flows, but limits the ability of an effective verification of the actual application of the required processing both to flows and individual packets. There are use cases where a strong evidence of each packet passing through a particular path in a chain is required, in particular in security-sensitive environments, and whenever high-priority policies have to be enforced. An archetypal case is network services applied in financial environments.
Since current practice for providing a strong evidence of SF application in these use cases requires physical verification of host chaining and direct topology evidence, these requirements virtually invalidate (or at least seriously limit) the application of SFC in those environments.
More technologies are therefore needed to assure the effective application of a chain of SFs to the data packets flows coming from a network to assure a given order of traversal of the SFs and to provide strong evidence that the data packets has traversed the correct path in the chain.